iT邦幫忙

2023 iThome 鐵人賽

DAY 28
1
AI & Data

當代資料工程與資料分析系列 第 28

實務應用:生產力相關的分析方法

  • 分享至 

  • xImage
  •  

之前談到效能改進時,有個關鍵點可以決定事倍功半或是事半功倍:「是否有利用工具去對系統內部做量測?」

很多時候,因為關鍵的性質難以量測或是預測,取而代之的替代方案就是:「假設已知性質 X 與性質 Y 有正相關,而性質 X 難以量測,但是性質 Y 容易量測,就把量測 Y 的結果視為量測到 X 又或是來預測 X。」當上述 X 與 Y 的相關性極高時,這樣子的變通之道還勉強可行,而實際上,隨著時間的前進,X 與 Y 的相關性到底還剩多少,很多人也搞不清楚了。以雇用員工這件事來講,常見的學歷主義,可以視為是一種透過學歷與員工生產力表現的正相關而做出的變通之道。

因為上述的現象,當變通之道量測的誤差愈來愈大時,一旦可以找出某種新的量測方法,可以取得更精準的量測,這個新的方法就可以帶來極高的價值,因為它甚至有機會可以導正一些扭曲的制度。

以下會來探討一些量測生產力相關因子的分析方法。

人均生產力

有一回與朋友聊天,朋友提到他的前公司是一間 IT 服務公司,年營收 3 億台幣,員工 150 人,而該公司的經營者為了要拼股票上市,還在積極設法擴張。我聽完後做了一些試算,覺得有點不妙,只能說,恭喜我朋友離職了。

該公司的人均生產力,即年營收除以員工人數,為 200 萬台幣。如果只看員工人數 150 人,這已經接近了大企業的經營規模,但是,如果也看人均生產力的話,這個人均生產力則是遠遠低於大企業的平均水準。

台灣經濟部中小企業處的報告「中小企業發展面臨問題與因應對策」之中有 2016 年的人均生產力統計數字:

  • 中小型製造業為 186 萬元
  • 中小型服務業為 120 萬元。
  • 大企業為 1,854 萬元。

這邊衍生了一個重要問題,企業應該先做設法做大、還是設法提高人均生產力?絕大多數的時刻,設法提高人均生產力才是正確的方向。甚至更直接一點來說,企業往往是因為人均生產力高,才有辦法長大;而不是因為長大了之後,人均生產力容易提高。

人均生產力是企業管理的重要指標,活用這個指標可以有效地提醒企業,內部是否充斥著不能產生(投資報酬率)的計畫。

軟體開發團隊的運作效能 (performance)

在企業來講,業務人員的績效通常最容易量測,因為與銷售數字高度相關,另一方面,研發人員的效能光是如何定義,都是一大問題。而軟體開發團隊的運作效能該如何量測、評估,更是沒有客觀的標準,多數的時候,主管也只是憑感覺來做評估。

DORA 研究計畫 提出了一組「四項關鍵指標」框架,而這四項指標與軟體開發團隊的運作效能好壞,有明顯的代表性與關聯性,足以做為重要的參考標準。這四項指標分別是:

  1. 布署前準備時間 (delivery lead time)
  2. 布署頻率 (deployment frequency)
  3. 平均錯誤修復時間 (mean time to restore)
  4. 改變失敗率 (change fail rate)

此處有兩件事值得我們特別注意,足以做為設計指標來量測其它不同型態工作的原則:

  1. 四項關鍵指標的每一項指標都是全域量測。對全域做量測的話,任何的團隊才不容易被錯誤的指標誘導而去做出「對自己管理的局部做最佳化,但是對全局而言,並非最佳化的選項」。
  2. 四項關鍵指標裡,指標兩兩成對,比方說,指標 1 與 2 都是量測推出新功能速度的指標,而指標 3 與 4 都是量測穩定性的指標。再更加細看的話,指標 2 與指標 4 都是量測"相對比率",而指標 1 與 3 則是量測"絕對速度"。

下圖是與四項關鍵指標相關的因果關系圖。

dora.png

軟體開發的技術債

在軟體開發的領域,由於人會犯錯、規格不夠明確等因素,軟體系統在設計時,總是會有沒有設計良好的部分,而且這些不良部分會在日後導致軟體開發速度減慢。這些設計不良又稱之為技術債,暗喻著:「你不花時間去修正它們,你就得一直付出時間利息。」

許多軟體工程師都在職涯之中面對兩個難題:

  1. 擔任工程師時,覺得難以說服上司,撥出足夠的時間,讓他們償還技術債。
  2. 擔任主管時,覺得難以說服下屬,不要花費過多的時間,償還所有的技術債。

那有沒有什麼客觀的參考標準,可以做為投資時間來改善技術債的準則呢?Your Code as a Crime Scene 就提出了技術債相關的分析法。

參考下圖,很多的軟體專案,即使程式語言不同,程式碼還是會有相似的結構:

code_scene_erlang.png

  • 把每個檔案標以一個數字放在 X 軸,把每個檔案對應的修改次數放在 Y 軸,並且把檔案依照修改次數排序就可以得到一個幕次分配 (power law distribution)
  • 做出幕次分配圖之後,就可以很快地定位出,有少數的檔案,它們是極為重要的檔案 (下圖左側藍底紅條紋的區塊)。
  • 而技術債如果位於重要檔案之上的話,通常只佔整個專案的 2%~4% 的程式碼,對它們做出改進之後,有相對很高的機率可以得到不錯的回報。

important_code.png


其它資源

  1. 對 dbt 或 data 有興趣 👋?歡迎加入 dbt community 到 #local-taipei 找我們,也有實體 Meetup 請到 dbt Taipei Meetup 報名參加
  2. 歡迎訂閱 PruningSuccess 電子報,主要談論軟體開發、資料處理、資料分析等議題。

上一篇
實務應用:成效相關的分析方法
下一篇
實務應用:機會相關的分析方法
系列文
當代資料工程與資料分析30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言